陸續導入幾個站台後，Jerry跟主管報告可以將交易類型的站台進行導入，並先以規模小的開始。

雖然規模比較小，但也至少200-300家廠商需要聯繫跟通知，因此選定在半夜進行導入。

導入當天，幾家廠商配合測試都沒什麼問題，於是就放心回家了。

SNI的請求

大約隔天中午時分，AP打來問Jerry，有一個客戶早上要連線一直無法成功，給你IP查一下看有沒有擋住。

Jerry來回看著阻擋或是存取的日誌，都沒有發現關於這個IP的連線紀錄。

於是Jerry請求顧問協助，並問到有幾種可能是連紀錄都沒有的情況，顧問回答:

1. 直接官方黑名單，如果是直接攻擊CDN主機的來源，官方有自己的一套防護機制，被擋掉的不會有紀錄。
2. TLS交握異常，程式所使用的協定或加密協議等問題，這個異常同樣不會有紀錄可以查。

但是，請求的異常，客戶端使用的工具應該會有訊息才是，請對方提供訊息看看。

當客戶提供訊息來時，說明是跟SNI error有關的資訊。

顧問立即明白了問題在哪，於是就跟Jerry解釋問題在哪裡。

在HTTPS的早期，可能很多是一個IP對應一個域名，因此伺服器不用判斷要給哪一張憑證。

但隨著一個IP後面，需要大量對應著不同域名時，就會需要SNI (伺服器名稱指示)。

當瀏覽器嘗試連線到HTTPS網站的第一步是 Client Hello 訊息，此訊息會透過告訴伺服器「我想要啟動安全工作階段」來啟動 TLS 交握，使用 SNI 時，瀏覽器會在 Client Hello 訊息中包含預期的主機名稱。

在解釋完SNI後，顧問說明，我猜廠商程式應該是採Standard的TLS交握機制，所以沒有帶SNI來。

但是Akamai預設會啟用僅接受來源帶有SNI資訊的請求，因此造成異常無法存取。

目前只能請廠商改程式了，因為因為如果關閉這個設定，Akamai就要幫這個站台保留且指定一個專屬的IP。這個除了額外的費用外，現在IPV4資源珍貴會不會讓你申請都不知道?

當Jerry回報給AP單位說明原因後，主管決定等廠商改好後再上線，因為這個合作廠商算是老客戶，也貢獻了不少訂單，要體諒廠商。

Jerry心想，不知道要改到何年何月!!

憑證沒指定位置

終於輪到了重要的電子商務站台要上線了，這個站台最特別的是會透過APP來存取服務。

而這個APP還特別去申請行動應用App資安檢測，來強調服務的安全性。

在該項檢測基準中有一條 4.1.4.2.2 “行動應用程式應確認伺服器憑證之有效性”，就是檢查行動應用程式是否使用憑證綁定（Certificate Pinning）方式驗證，以確保連線之伺服器為行動應用程式開發者所指定。

簡單說，會在APP中綁定SERVER端的憑證，以確保連線的對象是正確的主機，避免中間人攻擊的威脅。

透過一台破筆電完成APP的測試後，AP告知可以上線了。

結果上線當天，開發的同仁用了自己的手機測試正常，也請了其他開發部門的同仁測試也都沒有問題。

但當Jerry拿起自己的Google Pro手機測試時，卻出現了網路連線異常的告警!!

Jerry立即跟開發同仁告知這個問題，聽到開發同仁說~~啊!不是都有包版嗎?你不是測了!

正當開發同仁還在確認誰有測沒測時，Jerry立即將DNS切回地端，避免影響了服務。

後來開發請了協力廠商來確認原因，原來Android的部分需要特別指定要綁定憑證的路徑，否則會吃不到。

在確認原因後，就是要在要再上一次線。

有多個SDK

再次上線，這次開發兩種機型都測試沒有問題，Jerry終於鬆了口氣，專案終於可以交差結案了。

開心不了多久，有客戶報修有一個功能無法使用!!

結過開發一聽到那個功能，就叫了一聲~ 啊!!還有這個SDK也會驗憑証啦，我忘了改!!

所以Jerry又將DNS切回地端，只能再等待開發改好再上線

幾次下來，Jerry發現以往他只關注自己會的領域，但這次導入CDN的專案真是讓他大開眼界，也讓他感嘆自己的職能看來還差很遠，出了意外都只能依賴別人才能處理。

Jerry暗自心想，除了自己的領域專業外，未來其他人的會議或是專案，自己要認真地聽多學一點東西，說不定哪天可以派上用場!!